Linux 动态链接过程中的【重定位】底层原理
The following article is from IOT物联网小镇 Author 道哥
目录
动态链接要解决什么问题？
矛盾：代码段不可写
解决矛盾：增加一层间接性
示例代码
b.c
a.c
main.c
编译成动态链接库
动态库的依赖关系
动态库的加载过程
动态链接器加载动态库
动态库的加载地址分析
符号重定位
全局符号表
全局偏移表GOT
liba.so动态库文件的布局
liba.so动态库的虚拟地址
GOT表的内部结构
反汇编liba.so代码
在上一篇文章中，我们一起学习了Linux系统中 GCC编译器在编译可执行程序时，静态链接过程中是如何进行符号重定位的。GCC 链接过程中的【重定位】过程分析
为了完整性，我们这篇文章来一起探索一下：动态链接过程中是如何进行符号重定位的。
老样子，文中使用大量的【代码+图片】的方式，来真实的感受一下实际的内存模型。
文中使用了大量的图片，建议您在电脑上阅读此文。
关于为什么使用动态链接，这里就不展开讨论了，无非就几点：
节省物理内存;
可以动态更新;
动态链接要解决什么问题？
静态链接得到的可执行程序，被操作系统加载之后就可以执行执行。
因为在链接的时候，链接器已经把所有目标文件中的代码、数据等Section，都组装到可执行文件中了。
并且把代码中所有使用的外部符号(变量、函数)，都进行了重定位(即：把变量、函数的地址，都填写到代码段中需要重定位的地方)，因此可执行程序在执行的时候，不依赖于其它的外部模块即可运行。
详细的静态链接过程，请参考上一篇文章：GCC 链接过程中的【重定位】过程分析。
也就是说：符号重定位的过程，是直接对可执行文件进行修改。
但是对于动态链接来说，在编译阶段，仅仅是在可执行文件或者动态库中记录了一些必要的信息。
真正的重定位过程，是在这个时间点来完成的：可执行程序、动态库被加载之后，调用可执行程序的入口函数之前。
只有当所有需要被重定位的符号被解决了之后，才能开始执行程序。
既然也是重定位，与静态链接过程一样：也需要把符号的目标地址填写到代码段中需要重定位的地方。
矛盾：代码段不可写
问题来了!
我们知道，在现代操作系统中，对于内存的访问是有权限控制的，一般来说：
代码段：可读、可执行;
数据段：可读、可写;
如果进行符号重定位，就需要对代码进行修改(填写符号的地址)，但是代码段又没有可写的权限，这是一个矛盾！
解决这个矛盾的方案，就是Linux系统中动态链接器的核心工作！
解决矛盾：增加一层间接性
David Wheeler有一句名言:“计算机科学中的大多数问题，都可以通过增加一层间接性来解决。”
解决动态链接中的代码重定位问题，同样也可以通过增加一层间接性来解决。
既然代码段在被加载到内存中之后不可写，但是数据段是可写的。
在代码段中引用的外部符号，可以在数据段中增加一个跳板：让代码段先引用数据段中的内容，然后在重定位时，把外部符号的地址填写到数据段中对应的位置，不就解决这个矛盾了吗？!
如下图所示：
理解了上图的解决思路，基本上就理解了动态链接过程中重定位的核心思想。
示例代码
我们需要3个源文件来讨论动态链接中重定位的过程：main.c、a.c、b.c，其中的a.c和b.c被编译成动态库，然后main.c与这两个动态库一起动态链接成可执行程序。
它们之间的依赖关系是：
b.c
代码如下：
#include <stdio.h>
int b = 30;
void func_b(void)
{
printf("in func_b. b = %d \n", b);
}
代码说明：
定义一个全局变量和一个全局函数，被 a.c 调用。
a.c
代码如下(稍微复杂一些，主要是为了探索：不同类型的符号如何处理重定位)：
#include <stdio.h>
// 内部定义【静态】全局变量
static int a1 = 10;
// 内部定义【非静态】全局变量
int a2 = 20;
// 声明外部变量
extern int b;
// 声明外部函数
extern void func_b(void);
// 内部定义的【静态】函数
static void func_a2(void)
{
printf("in func_a2 \n");
}
// 内部定义的【非静态】函数
void func_a3(void)
{
printf("in func_a3 \n");
}
// 被 main 调用
void func_a1(void)
{
printf("in func_a1 \n");
// 操作内部变量
a1 = 11;
a2 = 21;
// 操作外部变量
b = 31;
// 调用内部函数
func_a2();
func_a3();
// 调用外部函数
func_b();
}
代码说明：
定义了 2 个全局变量：一个静态，一个非静态；
定义了 3 个函数:
func_a2是静态函数，只能在本文件中调用;
func_a1和func_a3是全局函数，可以被外部调用;
在 main.c 中会调用 func_a1。
main.c
代码如下：
#include <stdio.h>
#include <unistd.h>
#include <dlfcn.h>
// 声明外部变量
extern int a2;
extern void func_a1();
typedef void (*pfunc)(void);
int main(void)
{
printf("in main \n");
// 打印此进程的全局符号表
void *handle = dlopen(0, RTLD_NOW);
if (NULL == handle)
{
printf("dlopen failed! \n");
return -1;
}
printf("\n------------ main ---------------\n");
// 打印 main 中变量符号的地址
pfunc addr_main = dlsym(handle, "main");
if (NULL != addr_main)
printf("addr_main = 0x%x \n", (unsigned int)addr_main);
else
printf("get address of main failed! \n");
printf("\n------------ liba.so ---------------\n");
// 打印 liba.so 中变量符号的地址
unsigned int *addr_a1 = dlsym(handle, "a1");
if (NULL != addr_a1)
printf("addr_a1 = 0x%x \n", *addr_a1);
else
printf("get address of a1 failed! \n");
unsigned int *addr_a2 = dlsym(handle, "a2");
if (NULL != addr_a2)
printf("addr_a2 = 0x%x \n", *addr_a2);
else
printf("get address of a2 failed! \n");
// 打印 liba.so 中函数符号的地址
pfunc addr_func_a1 = dlsym(handle, "func_a1");
if (NULL != addr_func_a1)
printf("addr_func_a1 = 0x%x \n", (unsigned int)addr_func_a1);
else
printf("get address of func_a1 failed! \n");
pfunc addr_func_a2 = dlsym(handle, "func_a2");
if (NULL != addr_func_a2)
printf("addr_func_a2 = 0x%x \n", (unsigned int)addr_func_a2);
else
printf("get address of func_a2 failed! \n");
pfunc addr_func_a3 = dlsym(handle, "func_a3");
if (NULL != addr_func_a3)
printf("addr_func_a3 = 0x%x \n", (unsigned int)addr_func_a3);
else
printf("get address of func_a3 failed! \n");
printf("\n------------ libb.so ---------------\n");
// 打印 libb.so 中变量符号的地址
unsigned int *addr_b = dlsym(handle, "b");
if (NULL != addr_b)
printf("addr_b = 0x%x \n", *addr_b);
else
printf("get address of b failed! \n");
// 打印 libb.so 中函数符号的地址
pfunc addr_func_b = dlsym(handle, "func_b");
if (NULL != addr_func_b)
printf("addr_func_b = 0x%x \n", (unsigned int)addr_func_b);
else
printf("get address of func_b failed! \n");
dlclose(handle);
// 操作外部变量
a2 = 100;
// 调用外部函数
func_a1();
// 为了让进程不退出，方便查看虚拟空间中的地址信息
while(1) sleep(5);
return 0;
}
纠正：代码中本来是想打印变量的地址的，但是不小心加上了 *，变成了打印变量值。最后检查的时候才发现，所以就懒得再去修改了。
代码说明：
利用 dlopen 函数(第一个参数传入 NULL)，来打印此进程中的一些符号信息(变量和函数);
赋值给 liba.so 中的变量 a2，然后调用 liba.so 中的 func_a1 函数;
编译成动态链接库
把以上几个源文件编译成动态库以及可执行程序：
$ gcc -m32 -fPIC --shared b.c -o libb.so
$ gcc -m32 -fPIC --shared a.c -o liba.so -lb -L./
$ gcc -m32 -fPIC main.c -o main -ldl -la -lb -L./
有几点内容说明一下：
-fPIC 参数意思是：生成位置无关代码(Position Independent Code)，这也是动态链接中的关键;
既然动态库是在运行时加载，那为什么在编译的时候还需要指明?
因为在编译的时候，需要知道每一个动态库中提供了哪些符号。Windows 中的动态库的显性的导出和导入标识，更能体现这个概念(__declspec(dllexport), __declspec(dllimport))。
此时，就得到了如下几个文件：
动态库的依赖关系
对于静态链接的可执行程序来说，被操作系统加载之后，可以认为直接从可执行程序的入口函数开始(也就是ELF文件头中指定的e_entry这个地址)，执行其中的指令码。
但是对于动态链接的程序来说，在执行入口函数的指令之前，必须把该程序所依赖的动态库加载到内存中，然后才能开始执行。
对于我们的实例代码来说：main程序依赖于liba.so库，而liba.so库又依赖于libb.so库。
可以用ldd工具来分别看一下动态库之间的依赖关系：
可以看出：
在 liba.so 动态库中，记录了信息：依赖于 libb.so;
在 main 可执行文件中，记录了信息：依赖于 liba.so, libb.so;
也可以使用另一个工具patchelf来查看一个可执行程序或者动态库，依赖于其他哪些模块。例如：
那么，动态库的加载是由谁来完成的呢？动态链接器！
动态库的加载过程
动态链接器加载动态库
当执行main程序的时候，操作系统首先把main加载到内存，然后通过.interp段信息来查看该文件依赖哪些动态库：
上图中的字符串/lib/ld-linux.so.2，就表示main依赖动态链接库。
ld-linux.so.2也是一个动态链接库，在大部分情况下动态链接库已经被加载到内存中了(动态链接库就是为了共享)，操作系统此时只需要把动态链接库所在的物理内存，映射到 main进程的虚拟地址空间中就可以了，然后再把控制权交给动态链接器。
动态链接器发现：main依赖liba.so，于是它就在虚拟地址空间中找一块能放得下liba.so的空闲空间，然后把liba.so中需要加载到内存中的代码段、数据段都加载进来。
当然，在加载liba.so时，又会发现它依赖libb.so，于是又把在虚拟地址空间中找一块能放得下libb.so的空闲空间，把libb.so中的代码段、数据段等加载到内存中，示意图如下所示：
动态链接器自身也是一个动态库，而且是一个特殊的动态库：它不依赖于其他的任何动态库，因为当它被加载的时候，没有人帮它去加载依赖的动态库，否则就形成鸡生蛋、蛋生鸡的问题了。
动态库的加载地址
一个进程在运行时的实际加载地址(或者说虚拟内存区域)，可以通过指令：$ cat /proc/[进程的 pid]/maps 读取出来。
例如：我的虚拟机中执行main程序时，看到的地址信息是：
黄色部分分别是：main, liba.so, libb.so 这3个模块的加载信息。
另外，还可以看到c库(libc-2.23.so)、动态链接器(ld-2.23.so)以及动态加载库libdl-2.23.so的虚拟地址区域，布局如下：
可以看出出来:
main可执行程序是位于低地址，所有的动态库都位于4G内存空间的最后1G空间中。
还有另外一个指令也很好用 $ pmap [进程的 pid]，也可以打印出每个模块的内存地址：
符号重定位
全局符号表
在之前的静态链接中学习过，链接器在扫描每一个目标文件(.o文件)的时候，会把每个目标文件中的符号提取出来，构成一个全局符号表。
然后在第二遍扫描的时候，查看每个目标文件中需要重定位的符号，然后在全局符号表中查找该符号被安排在什么地址，然后把这个地址填写到引用的地方，这就是静态链接时的重定位。
但是动态链接过程中的重定位，与静态链接的处理方式差别就大很多了，因为每个符号的地址只有在运行的时候才能知道它们的地址。
例如：liba.so引用了libb.so中的变量和函数，而libb.so中的这两个符号被加载到什么位置，直到main程序准备执行的时候，才能被链接器加载到内存中的某个随机的位置。
也就是说：动态链接器知道每个动态库中的代码段、数据段被加载的内存地址，因此动态链接器也会维护一个全局符号表，其中存放着每一个动态库中导出的符号以及它们的内存地址信息。
在示例代码main.c函数中，我们通过dlopen返回的句柄来打印进程中的一些全局符号的地址信息，输出内容如下：
上文已经纠错过：本来是想打印变量的地址信息，但是 printf 语句中不小心加上了型号，变成了打印变量值。
可以看到：在全局符号表中，没有找到liba.so中的变量a1和函数func_a2这两个符号，因为它俩都是static类型的，在编译成动态库的时候，没有导出到符号表中。
既然提到了符号表，就来看看这 3 个ELF文件中的动态符号表信息：
动态链接库中保护两个符号表：.dynsym(动态符号表: 表示模块中符号的导出、导入关系) 和 .symtab(符号表: 表示模块中的所有符号); .symtab 中包含了 .dynsym;
由于图片太大，这里只贴出 .dynsym 动态符号表。
绿色矩形框前面的Ndx列是数字，表示该符号位于当前文件的哪一个段中(即：段索引);
红色矩形框前面的Ndx列是UND，表示这个符号没有找到，是一个外部符号(需要重定位);
全局偏移表GOT
在我们的示例代码中，liba.so是比较特殊的，它既被main可执行程序所依赖，又依赖于libb.so。
而且，在liba.so中，定义了静态、动态的全局变量和函数，可以很好的概况很多种情况，因此这部分内容就主要来分析liba.so这个动态库。
前文说过：代码重定位需要修改代码段中的符号引用，而代码段被加载到内存中又没有可写的权限，动态链接解决这个矛盾的方案是：增加一层间接性。
例如：liba.so的代码中引用了libb.so中的变量b，在liba.so的代码段，并不是在引用的地方直接指向libb.so数据段中变量b的地址，而是指向了liba.so自己的数据段中的某个位置，在重定位阶段，链接器再把libb.so中变量b的地址填写到这个位置。
因为liba.so自己的代码段和数据段位置是相对固定的，这样的话，liba.so的代码段被加载到内存之后，就再也不用修改了。
而数据段中这个间接跳转的位置，就称作：全局偏移表(GOT: Global Offset Table)。
划重点：
liba.so的代码段中引用了libb.so中的符号b，既然b的地址需要在重定位时才能确定，那么就在数据段中开辟一块空间(称作：GOT表)，重定位时把b的地址填写到GOT表中。
而liba.so的代码段中，把GOT表的地址填写到引用b的地方，因为GOT表在编译阶段是可以确定的，使用的是相对地址。
这样，就可以在不修改liba.so代码段的前提下，动态的对符号b进行了重定位！
其实，在一个动态库中存在 2 个GOT表，分别用于重定位变量符号(section名称：.got)和函数符号( section 名称：.got.plt)。
也就是说：所有变量类型的符号重定位信息都位于.got中，所有函数类型的符号重定位信息都位于.got.plt中。
并且，在一个动态库文件中，有两个特殊的段(.rel.dyn和.rel.plt)来告诉链接器：.got和.got.plt这两个表中，有哪些符号需要进行重定位，这个问题下面会深入讨论。
liba.so动态库文件的布局
为了更深刻的理解.got和.got.plt这两个表，有必要来拆解一下liba.so动态库文件的内部结构。
通过readelf -S liba.so指令来看一下这个ELF文件中都有哪些section:
可以看到：一共有28个section，其中的21、22就是两个GOT表。
另外，从装载的角度来看，装载器并不是把这些sections分开来处理，而是根据不同的读写属性，把多个section看做一个segment。
再次通过指令 readelf -l liba.so ，来查看一下segment信息:
也就是说：
这28个section中(关注绿色线条)：
section 0 ~ 16 都是可读、可执行权限，被当做一个 segment;
section 17 ~ 24 都是可读、可写的权限，被动作另一个 segment;
再来重点看一下.got和.got.plt这两个section(关注黄色矩形框)：
可见：.got和.got.plt与数据段一样，都是可读、可写的，所以被当做同一个 segment被加载到内存中。
通过以上这2张图(红色矩形框)，可以得到liba.so动态库文件的内部结构如下：
liba.so动态库的虚拟地址
来继续观察liba.so文件segment信息中的AirtAddr列，它表示的是被加载到虚拟内存中的地址，重新贴图如下：
因为编译动态库时，使用了代码位置无关参数(-fPIC)，这里的虚拟地址从0x0000_0000开始。
当liba.so的代码段、数据段被加载到内存中时，动态链接器找到一块空闲空间，这个空间的开始地址，就相当于一个基地址。
liba.so中的代码段和数据段中所有的虚拟地址信息，只要加上这个基地址，就得到了实际虚拟地址。
我们还是把上图中的输出信息，画出详细的内存模型图，如下所示：
GOT表的内部结构
现在，我们已经知道了liba.so库的文件布局，也知道了它的虚拟地址，此时就可以来进一步的看一下.got和.got.plt这两个表的内部结构了。
从刚才的图片中看出：
.got 表的长度是 0x1c，说明有 7 个表项(每个表项占 4 个字节);
.got.plt 表的长度是 0x18，说明有 6 个表项;
上文已经说过，这两个表是用来重定位所有的变量和函数等符号的。
那么：liba.so通过什么方式来告诉动态链接器：需要对.got和.got.plt这两个表中的表项进行地址重定位呢？
在静态链接的时候，目标文件是通过两个重定位表.rel.text和.rel.data这两个段信息来告诉链接器的。
对于动态链接来说，也是通过两个重定位表来传递需要重定位的符号信息的，只不过名字有些不同：.rel.dyn和.rel.plt。
通过指令 readelf -r liba.so来查看重定位信息：
从黄色和绿色的矩形框中可以看出：
liba.so 引用了外部符号 b，类型是 R_386_GLOB_DAT，这个符号的重定位描述信息在 .rel.dyn 段中;
liba.so 引用了外部符号 func_b, 类型是 R_386_JUMP_SLOT，这个符号的重定位描述信息在 .rel.plt 段中;
从左侧红色的矩形框可以看出：每一个需要重定位的表项所对应的虚拟地址，画成内存模型图就是下面这样：
暂时只专注表项中的红色部分：.got表中的b, .got.plt表中的func_b，这两个符号都是libb.so中导出的。
也就是说：
liba.so的代码中在操作变量b的时候，就到.got表中的0x0000_1fe8这个地址处来获取变量b的真正地址；
liba.so的代码中在调用func_b函数的时候，就到.got.plt表中的0x0000_200c这个地址处来获取函数的真正地址；
反汇编liba.so代码
下面就来反汇编一下liba.so，看一下指令码中是如何对这两个表项进行寻址的。
执行反汇编指令：$ objdump -d liba.so，这里只贴出func_a1函数的反汇编代码：
第一个绿色矩形框(call 490 <__x86.get_pc_thunk.bx>)的功能是：把下一条指令(add)的地址存储到%ebx中，也就是：
%ebx = 0x622
然后执行: add $0x19de,%ebx，让%ebx加上0x19de，结果就是：%ebx = 0x2000。
0x2000正是.got.plt表的开始地址！
看一下第2个绿色矩形框：
mov -0x18(%ebx),%eax: 先用%ebx减去0x18的结果，存储到%eax中，结果是：%eax = 0x1fe8，这个地址正是变量b在.got表中的虚拟地址。
movl $0x1f,(%eax)：在把0x1f(十进制就是31)，存储到0x1fe8表项中存储的地址所对应的内存单元中(libb.so的数据段中的某个位置)。
因此，当链接器进行重定位之后，0x1fe8表项中存储的就是变量b的真正地址，而上面这两步操作，就把数值31赋值给变量b了。
第3个绿色矩形框，是调用函数func_b，稍微复杂一些，跳转到符号 func_b@plt的地方，看一下反汇编代码：
jmp指令调用了%ebx + 0xc处的那个函数指针，从上面的.got.plt布局图中可以看出，重定位之后这个表项中存储的正是func_b函数的地址(libb.so中代码段的某个位置)，所以就正确的跳转到该函数中了。
- EOF -
加主页君微信，不仅C/C++技能+1
主页君日常还会在个人微信分享C/C++开发学习资源和技术文章精选，不定期分享一些有意思的活动、岗位内推以及如何用技术做业余项目
加个微信，打开一扇窗
关注『CPP开发者』
看精选C/C++技术文章
点赞和在看就是最大的支持❤️